Systems and Methods for Dynamic Telematics Messaging

ABSTRACT

Systems and methods for dynamic telematics messaging in accordance with embodiments of the invention are disclosed. One embodiment includes a dynamic telematics messaging system includes at least one vehicle telematics device, and a dynamic telematics messaging server system including, at least one processor, and a memory containing a messaging application, wherein the messaging application directs the at least one processor to, obtain a first message data from the at least one vehicle telematics device encoded in a first message format, transcode the first message data into a second message format, process the transcoded message data, and provide the transcoded message data.

CROSS REFERENCE TO RELATED APPLICATIONS

The instant application claims priority to U.S. Provisional Patent Application No. 62/582,192, filed Nov. 6, 2017, the disclosure of which is hereby incorporated by reference in its entirety.

FIELD OF THE INVENTION

The present invention relates to system communication processing and more specifically to dynamically processing disparate messages.

BACKGROUND

Telematics is the integrated use of telecommunications and informatics. Telematics units are installed in vehicles to provide a variety of telematics functionality in the vehicle. This functionality includes, but is not limited to, emergency warning systems, navigation functionality, safety warnings, vehicle location determination, and automated driving assistance. Telematics units are also capable of recording data related to the operation of the vehicle and providing that information for analysis, whether in real-time or during a time when the vehicle is being serviced. This information can be used in a variety of applications, such as fleet tracking, shipment tracking, insurance calculations, and in vehicle management and service.

SUMMARY OF THE INVENTION

Systems and methods for dynamic telematics messaging in accordance with embodiments of the invention are disclosed. One embodiment includes a dynamic telematics messaging system includes at least one vehicle telematics device, and a dynamic telematics messaging server system including, at least one processor, and a memory containing a messaging application, wherein the messaging application directs the at least one processor to obtain a first message data from the at least one vehicle telematics device encoded in a first message format, transcode the first message data into a second message format, process the transcoded message data, and provide the transcoded message data.

In another embodiment, transcoding the first message data into a second message format includes classifying the first message data by identifying the first message format.

In a further embodiment, classifying the first message data includes locating a header searching the first message data for at least one identifier and decoding the at least one identifier.

In still another embodiment, the at least one identifier is selected from the group consisting of a vehicle telematics device serial number, a vehicle identification number, an event code pattern, message data size, a unique accumulator value, and an IP address.

In a still further embodiment, decoding the at least one identifier includes matching the identifier to a messaging profile.

In yet another embodiment, decoding the at least one identifier includes matching the identifier to a messaging profile.

In a yet further embodiment, the appropriate module is a sensor data module, and the sensor data module directs the processor to determine available sensor data in the transcoded message and compile dynamic message data by aggregating the available sensor data into the second message format.

In another additional embodiment, the second message format is a standardized message format and aggregating the available sensor data includes populating standardized fields associated with the available sensor data.

In a further additional embodiment, the sensor data module further directs the processor to convert units associated with the available sensor data to standard units.

In another embodiment again, the sensor data module further directs the processor to generate secondary data based on the available sensor data.

In a further embodiment again, the appropriate module is a reverse geocoding module, and the reverse geocoding module directs the processor to obtain location data from the first message data, determine the nearest address based on the location data, and provide the determined address.

In still yet another embodiment, the location data includes GPS data.

In a still yet further embodiment, a method for dynamics telematics messaging includes obtaining a first message data from the at least one vehicle telematics device encoded in a first message format, transcoding the first message data into a second message format, processing the transcoded message data, and providing the transcoded message data.

In still another additional embodiment, transcoding the first message data into a second message format includes classifying the first message data by identifying the first message format.

In a still further additional embodiment, classifying the first message data includes locating a header, searching the first message data for at least one identifier, and decoding the at least one identifier.

In still another embodiment again, the at least one identifier is selected from the group consisting of a vehicle telematics device serial number, a vehicle identification number, an event code pattern, message data size, a unique accumulator value, and an IP address.

In a still further embodiment again, processing the transcoded message data includes applying an appropriate processing module to the transcoded message data.

In yet another additional embodiment, the appropriate module is a sensor data module, and the method further includes determining available sensor data in the transcoded message and compiling dynamic message data by aggregating the available sensor data into the second message format.

In a yet further additional embodiment, the second message format is a standardized message format, and aggregating the available sensor data includes populating standardized fields associated with the available sensor data.

In yet another embodiment again, the appropriate module is a reverse geocoding module, and the method further includes obtaining location data from the first message data, determining the nearest address based on the location data, and providing the determined address.

Other objects, advantages and novel features, and further scope of applicability of the present invention will be set forth in part in the detailed description to follow, and in part will become apparent to those skilled in the art upon examination of the following, or may be learned by practice of the invention. The objects and advantages of the invention may be realized and attained by means of the instrumentalities and combinations particularly pointed out in the prepended claims.

BRIEF DESCRIPTION OF THE DRAWINGS

The description will be more fully understood with reference to the following figures, which are presented as exemplary embodiments of the invention and should not be construed as a complete recitation of the scope of the invention, wherein:

FIG. 1A is a conceptual illustration of a dynamic telematics messaging system in accordance with an embodiment of the invention;

FIG. 1B is a second conceptual illustration of a dynamic telematics messaging system in accordance with an embodiment of the invention;

FIG. 2A is a conceptual illustration of a vehicle telematics device in accordance with an embodiment of the invention;

FIG. 2B is a conceptual illustration of a dynamic messaging server in accordance with an embodiment of the invention;

FIG. 3A is a flow chart illustrating a process for generating dynamic message data in accordance with an embodiment of the invention;

FIG. 3B is a flow chart illustrating a process for directing messages to appropriate modules in accordance with an embodiment of the invention;

FIG. 4 is a flow diagram illustrating an implementation of a process for generating dynamic message data in accordance with an embodiment of the invention;

FIG. 5 is a flow chart illustrating a process for compiling dynamic message data in accordance with an embodiment of the invention;

FIG. 6 is a flow chart illustrating a process for generating dynamic message data in accordance with an embodiment of the invention; and

FIG. 7 is a flow chart illustrating a process for generating reverse geocoding message data in accordance with an embodiment of the invention.

DETAILED DESCRIPTION

Turning now to the drawings, systems and methods for dynamic telematics messaging in accordance with embodiments of the invention are disclosed. Fleets of vehicles are a core component of many industries such as logistics and personal transportation. In many cases, it can be beneficial to be able to monitor and track the status of vehicles within the fleet. As such, many vehicles are equipped with a vehicle telematics device. These vehicle telematics devices can obtain and/or measure a variety of data regarding the conditions and/or location of the vehicle along with receiving and transmitting data to remote server systems. In many designs, in order to facilitate the transmission and receiving of data to remote server systems, the data is formatted such that it can be understood and processed by the remote server system. However, traditional telematics messaging systems are static in nature, meaning that once they have been established, a great deal of work is typically needed to add or adjust any features, such as, but not limited to, message content and/or message structure. This work can potentially include a re-writing of the program source code of the telematics messaging system and/or updating the firmware of the vehicle telematics devices to conform to the new message formats.

Dynamic telematics messaging systems can be used to obtain and transcode messages from a wide variety of vehicle telematics devices to a standardized format. Further, dynamic telematics messaging systems can generate additional data based on received messages. For example, vehicle telematics devices may not have the capability to measure fuel efficiency, while a dynamic telematics messaging system can automatically calculate fuel efficiency based on other metrics received. In numerous embodiments, different modules can be implemented within dynamic telematics messaging systems to perform different data transformations. In many embodiments, modules are processes for processing message data. Dynamic telematics messaging systems can additionally be used to communicate with a variety of types of vehicle telematics devices using only a single gateway rather than an individual gateway for each type or variation of vehicle telematics device.

Dynamic telematics messaging systems offer an improvement over previous messaging systems in a number of ways that include, but are not limited to, allowing the automatic processing of a wide variety of messages which previously could not be processed using a single system. In many embodiments, dynamic telematics messaging systems improve the ability of the system to dynamically identify and process message data over the prior systems. In several embodiments, dynamic telematics messaging systems transcode messages when received messages have an absence of (or insufficient) identifying metadata. For example, many vehicle telematics devices may not include firmware version numbers, message format indicators, or any other identifier as appropriate to the requirements of a given application. In numerous embodiments, if received messages include some form of an identifier (e.g. a serial number, a vehicle identification number (VIN), user defined identifier, Internet Protocol (IP) address, etc.), but the identifier is insufficient to confirm the type of message, dynamic telematics messaging systems can perform processes to supplement the identification metadata. As such, dynamic telematics messaging systems can identify the type of message by analyzing message format. Consequently, vehicle telematics devices operating using legacy message formats can remain in use in the field while being interoperable with the dynamic telematics messaging system.

Dynamic Telematics Messaging Systems

Dynamic telematics messaging systems in accordance with embodiments of the invention can transmit a variety of data between a remote server system and vehicle telematics devices. A conceptual diagram of a dynamic telematics messaging system in accordance with an embodiment of the invention is shown in FIG. 1A. The dynamic telematics messaging system 10 includes a vehicle telematics device 20 that can communicate with a vehicle data bus 22, an input/output (I/O) interface 24, and/or a network 30 as appropriate to the requirements of specific applications of embodiments of the invention. In a variety of embodiments, vehicle telematics device 20 communicates with a dynamic messaging server system 40 via the network 30. In a variety of embodiments, the network 30 is the Internet. In many embodiments, the network 30 is any wired or wireless network, such as a cellular network or the Internet, between the vehicle telematics device 20 and the dynamic messaging server system 40. In a number of embodiments, the dynamic messaging server system 40 implemented using a single server system. In several embodiments, the dynamic messaging server system 40 is implemented using multiple server systems.

In a variety of embodiments, the vehicle telematics device 20 is installed in a vehicle having a vehicle data bus 22. In several embodiments, the vehicle telematics device 20 is connected to a vehicle diagnostic connector that provides access to the vehicle data bus 22. The vehicle telematics device 20 can obtain data from any of a variety of vehicle devices connected to the vehicle data bus 22 utilizing any of a variety of techniques as appropriate to the requirements of specific applications of embodiments of the invention. Vehicle devices can include, but are not limited to, engine sensors, electronic control unit (ECU) devices, alternator sensors, vibration sensors, voltage sensors, oxygen sensors, Global Positioning System (GPS) receivers, ignition devices, weight sensors, wireless network devices, and/or acceleration determination devices. Systems and methods for connecting to a vehicle data bus that can be utilized in accordance with embodiments of the invention are described in SAE J1978, titled “OBD II Scan Tool,” first published by SAE International of Troy, Mich. on Mar. 1, 1992 and last updated Apr. 30, 2002. Systems and methods for obtaining data from devices connected to a vehicle data bus are described in SAE J1979, titled “E/E Diagnostic Test Modes,” first published by SAE International on Dec. 1, 1991 and last updated Aug. 11, 2014. The disclosures of SAE J1978 and SAE J1979 are hereby incorporated by reference in their entirety. In a number of embodiments, the vehicle telematics device is connected directly, either wired or wirelessly, to one or more sensors within the vehicle and/or does not utilize the vehicle data bus 22. The vehicle telematics device 20 can include any of a variety of sensors and/or devices, including those described above with respect to the vehicle data bus and any described in more detail below, to obtain data regarding the status of the vehicle. The vehicle telematics device 20 can also communicate with any of a variety of sensors and/or devices using the I/O interface 24. The I/O interface 24 can be any connection, including wired and wireless connections, as appropriate to the requirements of specific applications of embodiments of the invention.

In several embodiments, the vehicle telematics device 20 is capable of executing scripts to read data and/or perform particular processes. These scripts can be pre-loaded on the device and/or obtained from the dynamic messaging server system 40, vehicle data bus 22, and/or the I/O interface 24 as appropriate to the requirements of specific applications of embodiments of the invention. The vehicle telematics device 20 can be self-powered and/or connected into the electrical system of the vehicle in which the vehicle telematics device 20 is installed. In a variety of embodiments, the vehicle telematics device is powered via the vehicle data bus 22 and/or the I/O interface 24. In many embodiments, the vehicle telematics device 20 utilizes a Global Positioning System (GPS) receiver in order to determine the location, speed, and/or acceleration of the vehicle. However, it should be noted that any location-determining techniques, such as cellular tower triangulation, wireless network geolocation techniques, and dead reckoning techniques, could be utilized as appropriate to the requirements of specific applications of embodiments of the invention.

In a variety of embodiments, the vehicle telematics device 20 and/or dynamic messaging server system 40 provides a user interface allowing for visualizing and interacting with the data transmitted and/or received between the systems. In several embodiments, the vehicle telematics device 20 and/or dynamic messaging server system 40 provide an interface, such as an application programming interface (API) or web service that provides some or all of the data to third-party systems for further processing. Access to the interface can be open and/or secured using any of a variety of techniques, such as by using client authorization keys, as appropriate to the requirements of specific applications of the invention.

Turning now to FIG. 1B, a conceptual illustration of a dynamic telematics messaging system in accordance with an embodiment of the invention is shown. Dynamic telematics messaging system 100 receives messages from vehicle telematics devices 110. Vehicle telematics device 110 can be connected to a vehicle 111. In a variety of embodiments, vehicle telematics devices can be directly connected to a vehicle bus via a diagnostic connector within the vehicle. However, many vehicle telematics devices are not connected to the vehicle bus, and collect data independently and/or through direct connections to the vehicle's information systems. vehicle telematics devices are configured to obtain and generate data regarding the operation of the vehicle, including event data 113, application data 114, user data 115, and/or acknowledgement data 116. Event data can describe automatic vehicle location data (e.g. GPS coordinates), key fob presence, collision data, or any other event related information as appropriate to the requirements of a given application. Application data can describe any data utilized for management of the vehicle telematics device and/or any status related data, such as, but not limited to, data received from the vehicle BUS, report identification numbers, or any other data as appropriate to the requirements of a given application. User data can be any type of data describing the vehicle user and/or user action, such as, but not limited to, personal navigation data. Acknowledgement data can describe whether or not previous messages from and/or to the vehicle telematics device have been acknowledged by corresponding systems.

In a variety of embodiments, a wireless access point 117 contains components similar to vehicle telematics devices. In many embodiments, wireless access points can accumulate data and perform similar processes as vehicle telematics devices. In numerous embodiments, vehicle telematics devices transmit data using the wireless access point. In a variety of embodiments, the wireless access point is cell phone, a modem, a router, or any other wireless communications device as appropriate to the requirements of a given application. Systems and methods for transmitting data using a wireless access point that can be utilized in accordance with embodiments of the invention are described in U.S. patent application Ser. No. 15/430,400 titled “Systems and Methods for Radio Access Interfaces” filed Feb. 10, 2017, and U.S. patent application Ser. No. 15/373,277 titled “Systems and Methods for Tracking Multiple Collocated Assets” filed Dec. 8, 2016, the disclosures of which are incorporated herein by reference in their entirety. Data can be transferred over a wireless communications network 120 to a dynamic messing server system 130. Messages transmitted to the dynamic messaging server system are obtained by a network processor 131 and stored in a queue to be processed by message processor 132. In many embodiments, message processors transcode received messages into a standardized message format. In numerous embodiments, message processors generate messages for transmission to vehicle telematics devices. As such, message processor 132 can be configured to store generated messages in a queue for transmission by the network processor 131 over the wireless communications network 120 back to vehicle telematics device 110.

Message processor 132 can further queue messages to be sent to data pump 133. Data pump 133 can be used to transmit messages between dynamic messaging server systems and user interface systems 170 via a network 150, such as the Internet. In many embodiments, the network 150 is configured to transmit messages using the hypertext transfer protocol using representational state transfer methods. However, any network protocol can be used to transmit data over the network as appropriate to the requirements of a given application.

The message processor 132 can further transmit messages to a message database 135. In numerous embodiments, message databases store standardized messages as records. In many embodiments, messages of various formats can be stored within message databases. The message database can be queried by a services module 140. Service modules comprise a set of core services 141, such as, but not limited to, applications that can process messages to produce meaningful data. Examples of core services include, but are not limited to, tracking a particular vehicle/set of vehicles, insurance claim data generation, route optimization, efficiency calculations, geofencing, or any other service as appropriate to the requirements of a given application. Core services can obtain service requests from interface systems 170, which can be passed through dynamic messaging server systems to the services module. Results can be generated and transmitted back via a similar route. In numerous embodiments, dynamic messaging server systems can generate a set of results to specific queries in addition to, or instead of, the services module. In many embodiments, service modules have databases 142 for storing data relevant to implementing various core services, including, but not limited to, relevant message records.

In numerous embodiments, storage module 160 can be connected to the message database 135 to store messages. Storage module 160 can include a storage database implemented using disk storage (disk database) 161 and/or a storage database implemented on main memory (in-memory database) 162. In numerous embodiments, the disk database is implemented using MongoDB. In a variety of embodiments, the in-memory database is implemented using Redis. However, any number of database implementations can be used in accordance with the requirements of a given application.

Although specific architectures of dynamic telematics messaging systems in accordance with embodiments of the invention are discussed above and illustrated in FIG. 1A-B, a variety of architectures, including sensors, servers, and other message data processing devices and techniques not specifically described above, can be utilized in accordance with embodiments of the invention. Furthermore, the processes described herein can be performed using any combination the vehicle telematics devices, server systems, and/or modules as appropriate to the requirements of specific applications of embodiments of the invention.

Vehicle Telematics Devices

Vehicle telematics devices in accordance with many embodiments of the invention can transmit and receive data via dynamic telematics messaging systems. A conceptual illustration of a vehicle telematics device in accordance with an embodiment of the invention is shown in FIG. 2A. The vehicle telematics device 200 includes a processor 210 in communication with a memory 240. In many embodiments, memory includes a series of accumulators configured to store bit strings. Accumulators can be assigned static identifiers, e.g. 0, 1 ,2 . . . etc. The vehicle telematics device 200 includes a communications interface 220 capable of sending and receiving data. Although the processor 210 and communications interface 220 are illustrated as separate components, some or all of these devices can be implemented using a single-chip solution as appropriate to the requirements of specific applications of embodiments of the invention.

In certain embodiments, sensor devices 230 can be included within the vehicle telematics device 200 and/or located external to the vehicle telematics device 200. Sensor devices 230 can include, but are not limited to, RPM sensors, voltage sensors, GPS receivers, noise sensors, vibration sensors, acceleration sensors, weight sensors, and any other device capable of measuring data regarding a vehicle as appropriate to the requirements of specific applications of embodiments of the invention. Sensor devices 230 can further include any sensor readings produced by sensors integrated into the vehicle, and transmitted to the vehicle telematics device. In many embodiments, sensor readings produced by sensors integrated into the vehicle and transmitted over the vehicle bus. In numerous embodiments, sensor readings are stored in the series of accumulators.

In several embodiments, the memory 240 is any form of storage configured to store a variety of data, including, but not limited to, a messaging application 242, device configuration data 244, and sensor data 246. In many embodiments, the messaging application 242, configuration data 244, and/or sensor data 246 are stored using an external server system and received by the vehicle telematics device 200 using the communications interface 220. Sensor data 246 can include any measurements taken by sensor devices. In numerous embodiments, sensor data is stored in accumulators. Sensor data can also include location data generated using a variety of methods including, but not limited to, utilizing GPS, cellular tower triangulation, wireless network geolocation techniques, dead reckoning techniques, and/or any other geolocation measurement system as appropriate to the requirements of a given application.

Turning now to FIG. 2B, a conceptual illustration of a dynamic messaging server system is shown. The dynamic messaging server system 260 includes a processor 270 in communication with a memory 290 and a communications interface 280. Processor 270 can be any type of computational processing unit, including, but not limited to, microprocessors, central processing units, graphical processing units, parallel processing engines, or any other type of processor as appropriate to the requirements of a given application. Memory 290 can be implemented using any combination of volatile and/or non-volatile memory, including, but not limited to, random access memory, read-only memory, hard disk drives, solid-state drives, flash memory, or any other memory format as appropriate to the requirements of a given application. The communications interface 280 can be utilized to transmit and receive messages from any of a variety of remote systems, such as vehicle telematics and remote server systems. Communications interfaces can include multiple ports and/or technologies in order to communicate with various devices as appropriate to the requirements of specific applications of embodiments of the invention as described above.

In several embodiments, the memory 290 is any form of storage configured to store a variety of data, including, but not limited to, a dynamic messaging application 292, received message data 293, and/or dynamic message data 294. In many embodiments, the dynamic messaging application 292, received message data 293, and/or dynamic message data 294 are stored using an external server system and received by the dynamic messaging server system 260 using the communications interface 280.

The processor 210 and the processor 270 can be directed, by messaging application 242 and dynamic messaging application 292 respectively, to perform a variety of dynamic telematics messaging processes. A number of dynamic telematics messaging processes in accordance with embodiments of the invention are described in more detail below.

Although specific architectures for vehicle telematics devices and dynamic messaging server systems in accordance with embodiments of the invention are conceptually illustrated in FIGS. 2A and 2B, any of a variety of architectures, including those that store data or applications on disk or some other form of storage and are loaded into memory at runtime, can also be utilized. In a variety of embodiments, a memory includes circuitry such as, but not limited to, memory cells constructed using transistors, that are configured to store instructions. Similarly, a processor can include logic gates formed from transistors (or any other device) that dynamically perform actions based on the instructions stored in the memory. In several embodiments, the instructions are embodied in a configuration of logic gates within the processor to implement and/or perform actions described by the instructions. In this way, the systems and methods described herein can be performed utilizing both general-purpose computing hardware and by single-purpose devices such as, but not limited to, systems-on-a-chip (SoC). Furthermore, dynamic messaging servers can be implemented on multiple servers within at least one server system. For example, dynamic messaging server systems can be implemented on various remote “cloud” server systems as appropriate to the requirements of a given application.

Dynamic Telematics Messaging

Vehicle telematics devices across a fleet of vehicles are often different models and/or operate using different messaging schemes. Dynamic telematics messaging systems can be used to harmonize the content and structure of messages received from different telematics units. In many embodiments, message data received from at least one vehicle telematics device in the fleet is not self-descriptive. That is, the message data does not identify what the data represents. In many embodiments, messages contain bit strings from accumulator registers and/or event codes from the originating vehicle telematics device. In some embodiments, event codes can be associated with accumulator register data. For example, event codes can be, but are not limited to, elapsed time, distance traveled, speed, maximum speed achieved, current acceleration/deceleration output, maximum acceleration/deceleration output, zone states, position accuracy estimates, input/output states, maximum acceleration and/or deceleration, received signal strength indication, communications network identification numbers, temperature, speed history, throttle position engine speed, odometer, fuel remaining, current gear, coolant temperature, fuel consumption rate, battery voltage, service interval inspection distance, oil temperature, or any other metric associated with the vehicle that the vehicle telematics device is attached to. The above list is not meant to be exhaustive, and one of ordinary skill in the art would recognize that any number of metrics can be associated with a vehicle.

Further, vehicle telematics devices can have multiple messaging profile types such that generated messages can have various orderings of data. In numerous embodiments, event codes are not all unique identifiers and/or do not expressly indicate the type of associate data. Despite receiving sparsely labeled and/or unlabeled data, Dynamic telematics messaging processes in accordance with embodiments of the invention can include harmonizing numerous different messages, in a variety of formats, from different vehicle telematics devices to a single messaging format.

Turning now to FIG. 3A, a process for generating dynamic message data in accordance with an embodiment of the invention is illustrated. Process 300 includes acquiring (302) message data and parsing (304) message data. Message data can be comprised of at least byte message data and metadata. Byte message data can include vehicle telematics device accumulator values, event type codes, or any other substantive information from a vehicle telematics device as appropriate to the requirements of a given application of the invention. Metadata can describe the various pieces of information about the byte message. In numerous embodiments, message data received are already contain dynamic message data. In many embodiments, if dynamic message data is received, then no further parsing steps are required. If the data received is an unlabeled message data, the message can be parsed to identify and/or label the unlabeled message data.

In numerous embodiments, parsing the message data involves analyzing the structure of the message data. In a variety of embodiments, parsing the message involves analyzing the content of the message. The message type is identified (306) and dynamic message data are generated (308). In numerous embodiments, dynamic message data is a standardized message format that labels each type of data contained in a received message data using a unique identifier. In some embodiments, the dynamic message data contains a field for each possible type of data receivable in a vehicle telematics device message. In a variety of embodiments, the dynamic message data only contains a field for the types of data received in the received vehicle telematics device message. However, any subset of the set of possible types of data can be used as a field in a dynamic message data in accordance with the requirements of a given application.

In many embodiments, dynamic messaging processes include parsing messages data. Parsing message data can include reading the content and/or structure of received message data and determining one or more processing modules to be used to transcode the message data to a standard format. Turning now to FIG. 3B, a process for directing message data to the appropriate module in accordance with an embodiment of the invention is illustrated. Process 310 includes searching (312) message data for headers. In numerous embodiments, headers are stored within the metadata corresponding to message data and/or generated when the message is initially received. Headers can indicate a source address, a source port, a protocol identifier, a message length, and/or any other metadata describing the message as appropriate to the requirements of embodiments of the invention. In many embodiments, not all messages have headers. In numerous embodiments, different message data have different amounts and/or types of metadata stored in headers. In a variety of embodiments, the headers can be updated headers with flags (or any other metadata) as it is processed.

Process 310 further includes decoding (314) identifiers. In numerous embodiments, identifiers can be headers. For example, in a variety of embodiments, identifiers can be part of the byte message data. Identifiers can include patterns of event codes that are unique to particular messaging profiles. Identifiers can also include accumulator values that are unique to specific event types. In many embodiments, identifiers can be extracted from a combination of byte message data and headers. For example, message size in addition to an event code location in the bit message can indicate the source vehicle telematics device type and/or messaging profile used to generate the message data. However, any combination of data can be used as an identifier as appropriate to the requirements of specific applications of embodiments of the invention.

Identifiers can be used to classify (316) message data types. In many embodiments, identifiers are matched against a database of identifiers associated with message data types. In several embodiments, message data types are messaging profiles that describe the labels for the data in a particular message data format. Multiple messaging profiles can be associated with the same vehicle telematics device type. Message data types can include, but are not limited to, messages regarding event reporting, vehicle telematics device identification, user data, application data, configuration settings, data requests, location reports, accumulator logs, collision reports, acknowledged status, not acknowledged status, and/or any other messaging type as appropriate to the requirements of a given application. In numerous embodiments, a single message can contain data associated with more than one type. In a variety of embodiments, if no type can be determined, the message data can be placed in a queue for unrecognized messages. Unrecognized messages can be flagged for manual processing, and/or stored in a log file associated with the vehicle telematics device.

Once the vehicle telematics device message type is identified, the message data, in whole or in part, can be processed (318) based on the identified classification. In many embodiments, each messaging type is parsed differently based on the message data type. In numerous embodiments, message data are labeled according to a set of rules for the particular processing stream. In the event that message data is unable to be fully parsed, all or part of the message can be flagged and/or stored in the log file associated with the vehicle telematics device.

While a variety of methods for generating and parsing message data are described above with respect to FIGS. 3A and 3B, one of ordinary skill in the art would appreciate that any number of parsing methods could be used in accordance with the requirements of a given application of the invention.

Processing Messages Using Dynamic Telematics Messaging Systems

Dynamic telematics messaging processes in accordance with embodiments of the invention can include generating dynamic messaging data based on received. Turning now to FIG. 4, a conceptual illustration of a processor for generating dynamic message data in accordance with an embodiment of the invention is shown. The processor 400 includes incoming messages that interface with a message processor 410. In many embodiments, an uplink message consumer 430 interfaces with an uplink message broker 431 to generate and/or receive a network message 432 that is sent to or received from the message processor 410. The message processor 410 includes a message service handler 411, a message converter 412, message module processor 413, and service/module locater 414. The message processor 410 can also include internal modules 415 and/or external modules 416. Exception handling systems 420 may include generated exception data 421, an exception handler 422 and a failed message queue 423. The failed message queue may then be reprocessed by a failed message consumer 440, and failed message broker 441 to generate a failed message 442.

Incoming messages generated from application interface events can be acquired through an uplink message consumer 430. In many embodiments, the uplink message consumer is a polling consumer. In certain embodiments, received messages can be processed through an uplink message broker 431 to generate a network message 432 in a proper format for processing. In numerous embodiments, each message consumer includes an integrated exception handler to handle any exceptions that occur during processing.

The message processor 410 enriches incoming network messages 432. In several embodiments, the message processor 410 receives network messages 432 via the message service handler 411. In a variety of embodiments, the message service handler 411 measures the network message 432 for device configuration data that can be utilized to determine core services necessary for processing of the message 432. The message converter 412 converts the message from a network message 432 into event object data. In a number of embodiments, the event object data is in a self-described format. In a variety of embodiments, the message module processor 413 correlates event object data with subscription data to determine modules that can be utilized by the message processor 410 to process the event object data. The service/module locator 414 loads core services and modules based on the enriched event object data.

Modules can be stored internally 415 or externally 416 based on the needs of the application. Modules can be utilized based on a variety of factors including, but not limited to, configuration data, subscription data, the type of message, and/or the specific need of the application. For example, modules can be dynamically applied in dynamic telematics messaging systems based on the type of device that sent the message or by messages processed from a certain client. In many embodiments, a module for converting event object data into behavior data is utilized for further analysis and processing. Modules are dynamically applied to the message processor, thereby allowing for the creation of new modules as needed.

In several embodiments, each type of module 415, 416 handles its own exceptions through an exception handling process 420. When exceptions occur, exception data 421 can be generated. In a variety of embodiments, the exception data 421 is processed by an exception handler 422. In many embodiments, based on the rules of the exception handler 422, the event object is added to a failed message queue 423. A failed message consumer 440 receives the failed message from the failed message queue 423. In many embodiments, the failed message is processed by a failed message broker 441 to generate a failed message pass (MP) message 442 in a format suitable for processing by the message processor 410. In a variety of embodiments, the message service handler 411 receives the failed MP message 442 and only invokes the modules or services that generated the exception data from the previous message processing.

Specific structures for processing messages in accordance with embodiments of the invention are described above and shown with respect to FIG. 4. However, any number of structures, including those that utilize multiple or remotely accessed message consumers, modules, and/or core services can be utilized as appropriate to the requirements of specific applications in accordance with embodiments of the invention.

Generating Dynamic Message Data

Dynamic telematics messaging processes in accordance with embodiments of the invention can include generating dynamic message data. Dynamic message data can be generated by compiling parsed vehicle telematics device messages. In numerous embodiments, dynamic message data also includes new data generated by dynamic telematics messaging systems from parsed vehicle telematics device messages. In many embodiments, older vehicle telematics devices are not capable of producing the same types of data as newer vehicle telematics devices. However, some newer types of data can be calculated and/or approximated from older vehicle telematics device data types. In numerous embodiments, new data generate by dynamic telematics messaging systems incorporates data or processing capabilities not available to the vehicle telematics devices, such as, but not limited to, map data, impact detection processing, or any other calculation or data set as appropriate to the requirements of a given application.

Turning now to FIG. 5, a process for compiling parsed vehicle telematics device messages into dynamic message data in accordance with an embodiment of the invention is shown. Process 500 includes obtaining (510) parsed message data. In numerous embodiments, parsed message data includes event type and accumulator value pairs. Relevant processing modules can be identified (512). In a variety of embodiments, the processing modules are identified based on the parsed message data. In several embodiments, additional data can be generated (514). In many embodiments, the additional data is generated (514) by one or more processing modules. Processing modules can include calculations, data management capabilities, and/or data sets that can be used in conjunction with parsed message data. For example, GPS data (or other locational data) obtained in a vehicle telematics device message can be used to reverse geo code the street and/or nearby address location of a vehicle telematics device. By way of a second example, a remaining drive time can be calculated based on fuel level, elapsed time, and/or distance traveled. However, any number of calculations can be performed by modules to generate (514) additional data from received messages using modules as appropriate to the requirements of specific applications of embodiments of the invention.

Data, including parsed message data and/or additional data, can be labeled (516) and compiled (518) into dynamic message data. Labeling parsed message data can include, but is not limited to, adding appropriate units, adding additional metadata, or formatting the message data structure in such a way that the type of data is readily apparent. For example, the parsed message data can be labeled using a variety of extensible markup language (XML) tags, although any label metadata can be utilized as appropriate to the requirements of specific applications of embodiments of the invention.

Specific processes for generating additional data and/or labeling data in accordance with embodiments of the invention are described above and shown with respect to FIG. 5; however, any number of processes, including those that use alternative techniques for generating data and other message formats, such as JSON, can be utilized as appropriate to the requirements of a specific application in accordance with embodiments of the invention.

Processing Sensor Data

Sensor data can be stored within message data. Dynamic telematics messaging processes can include determining the kinds of sensor readings that are present within a given message and/or produce additional data based on received data to provide useful data. Turning now to FIG. 6, a process for generating dynamic message data in accordance with an embodiment of the invention is illustrated. Process 600 includes determining (610) available data from a message. In many embodiments, the type data is determined prior to initializing processing using the module. In numerous embodiments, a vehicle telematics device sensor data module determines the type of data contained within a message. Once the type of data is determined, the data can be converted (612) to standardized units. In numerous embodiments, measurements obtained by vehicle telematics device sensor devices are measured in imperial units. In a variety of embodiments, measurements described by sensor data are in metric units. However, any unit, including novel units can be used to label measured data and vehicle telematics device sensor data modules can be configured to and from any standardized unit format as appropriate to the requirements of specific applications of embodiments of the invention.

Process 600 can also include generating (614) secondary data based on the determined available data. In numerous embodiments, information regarding the vehicle and/or sensors that the vehicle telematics device that originated the message in installed and/or connected to can be utilized to identify secondary data. For example, the accumulator configuration for a particular device can be determined based on the vehicle identification number (VIN) for the vehicle; the accumulator configuration can be utilized to decode and process the message data received as described above. In numerous embodiments, a time to next vehicle service requirement can be calculated based on odometer readings and/or vehicle service history data. In a variety of embodiments, an estimated time to arrival at a destination can be calculated based on current time, the location of the vehicle, and the average speed of the vehicle. However, any number of different calculations, including alternate methods of calculating the same data, can be performed by vehicle telematics device sensor data modules as appropriate to the requirements of a given application of embodiments of the invention.

Process 600 also includes generating (616) dynamic message data by aggregating received data and generated secondary data into a standard dynamic message structure. In numerous embodiments, the standard dynamic message structure has standardized fields for different types of data. In many embodiments, the vehicle telematics device sensor data module provides the available data and the generated secondary data to the message processor to compile the dynamic message data.

Specific processes for generating dynamic messaging data in accordance with embodiments of the invention are described above and shown with respect to FIG. 6; however, any number of processes, including those that use alternative techniques for processing different types of sensor data, can be utilized as appropriate to the requirements of a specific application in accordance with embodiments of the invention.

Reverse Geocoding

Reverse geocoding is the process of determining a nearest address to a specific geographic coordinate. Message data can include location data describing where the message originated. In many embodiments, address based location information can be useful for asset tracking. In numerous embodiments, data such as GPS coordinates can be unreliable. For example, in areas with numerous obstacles (e.g. buildings in an urban setting), GPS data can be unreliable. Location data can include a variety of alternative location data such as, but not limited to, geolocation derived from IP addresses associated with wireless networks. Alternative location data can be used to augment other location data and/or to improve the process of locating the point of origin of the message data. Dynamics telematics messaging processes in accordance with embodiments of the invention can include automatically reverse geocoding location data to include location data in the dynamic message data.

Turning now to FIG. 7, a process for providing an address based on location data in accordance with an embodiment of the invention is illustrated. Process 700 includes obtaining (710) location data. In many embodiments, location data is confirmed (712). Location data can be confirmed in a variety of ways, including, but not limited to, performing sanity checks against previously reported locations, utilizing an alternate method of obtaining location, estimating the expected location based on historical speed and/or position data, and/or any other confirmation technique as appropriate to the requirements of a given application. Reverse geolocation techniques can be applied to the location data to determine (714) the nearest address. In many embodiments, location data is used to search a map for the nearest address. In numerous embodiments, the nearest address is a street address. In a variety of embodiments, the nearest address is a label that describes a specific geographic region (e.g. a Cartesian coordinate on a grid overlaid on a map, or any other labeling system appropriate to the requirements of a given application). The determined address can be provided (716). In many embodiments, the determined address is provided to an interface device, a message processor, and/or any other component as appropriate to the requirements of a given application.

Specific processes for reverse geocoding in accordance with embodiments of the invention are described above and shown with respect to FIG. 7; however, any number of processes, including those that use alternative techniques for reverse geocoding and/or different types of location data, can be utilized as appropriate to the requirements of a specific application in accordance with embodiments of the invention.

Although the present invention has been described in certain specific aspects, many additional modifications and variations would be apparent to those skilled in the art. In particular, any of the various processes described above can be performed in alternative sequences and/or in parallel in order to achieve similar results in a manner that is more appropriate to the requirements of a specific application. It is therefore to be understood that the present invention can be practiced otherwise than specifically described without departing from the scope and spirit of the present invention. Thus, embodiments of the present invention should be considered in all respects as illustrative and not restrictive. It will be evident to the person skilled in the art to freely combine several or all of the embodiments discussed here as deemed suitable for a specific application of the invention. Throughout this disclosure, terms like “advantageous”, “exemplary” or “preferred” indicate elements or dimensions which are particularly suitable (but not essential) to the invention or an embodiment thereof, and may be modified wherever deemed suitable by the skilled person, except where expressly required. Accordingly, the scope of the invention should be determined not by the embodiments illustrated, but by the appended claims and their equivalents. 

What is claimed is:
 1. A dynamic telematics messaging system comprising: at least one vehicle telematics device; and a dynamic telematics messaging server system comprising: at least one processor; and a memory containing a messaging application, wherein the messaging application directs the at least one processor to: obtain a first message data from the at least one vehicle telematics device encoded in a first message format; transcode the first message data into a second message format; process the transcoded message data; and provide the transcoded message data.
 2. The dynamic telematics messaging system of claim 1, wherein transcoding the first message data into a second message format comprises classifying the first message data by identifying the first message format.
 3. The dynamic telematics messaging system of claim 2, wherein classifying the first message data comprises: locating a header; searching the first message data for at least one identifier; and decoding the at least one identifier.
 4. The dynamic telematics messaging system of claim 3, wherein the at least one identifier is selected from the group consisting of a vehicle telematics device serial number, a vehicle identification number, an event code pattern, message data size, a unique accumulator value, and an IP address.
 5. The dynamic telematics messaging system of claim 3, wherein decoding the at least one identifier comprises matching the identifier to a messaging profile.
 6. The dynamic telematics messaging system of claim 2, wherein processing the transcoded message data comprises applying an appropriate processing module to the transcoded message data.
 7. The dynamic telematics messaging system of claim 3, wherein the appropriate module is a sensor data module, and the sensor data module directs the processor to: determine available sensor data in the transcoded message; and compile dynamic message data by aggregating the available sensor data into the second message format.
 8. The dynamic telematics messaging system of claim 7, wherein the second message format is a standardized message format; and aggregating the available sensor data comprises populating standardized fields associated with the available sensor data.
 9. The dynamic telematics messaging system of claim 7, wherein the sensor data module further directs the processor to convert units associated with the available sensor data to a standard units.
 10. The dynamic telematics messaging system of claim 7, wherein the sensor data module further directs the processor to generate secondary data based on the available sensor data.
 11. The dynamic telematics messaging system of claim 3, wherein the appropriate module is a reverse geocoding module, and the reverse geocoding module directs the processor to: obtain location data from the first message data; determine the nearest address based on the location data; and provide the determined address.
 12. The dynamic telematics messaging system of claim 11, wherein the location data comprises GPS data.
 13. A method for dynamics telematics messaging comprising: obtaining a first message data from the at least one vehicle telematics device encoded in a first message format; transcoding the first message data into a second message format; processing the transcoded message data; and providing the transcoded message data.
 14. The method of claim 13, wherein transcoding the first message data into a second message format comprises classifying the first message data by identifying the first message format.
 15. The method of claim 14, wherein classifying the first message data comprises: locating a header searching the first message data for at least one identifier; and decoding the at least one identifier.
 16. The method of claim 15, wherein the at least one identifier is selected from the group consisting of a vehicle telematics device serial number, a vehicle identification number, an event code pattern, message data size, a unique accumulator value, and an IP address.
 17. The method of claim 13, wherein processing the transcoded message data comprises applying an appropriate processing module to the transcoded message data.
 18. The method of claim 13, wherein the appropriate module is a sensor data module, and the method further comprises: determining available sensor data in the transcoded message; and compiling dynamic message data by aggregating the available sensor data into the second message format.
 19. The method of claim 18, wherein the second message format is a standardized message format; and aggregating the available sensor data comprises populating standardized fields associated with the available sensor data.
 20. The method of claim 13, wherein the appropriate module is a reverse geocoding module, and the method further comprises: obtaining location data from the first message data; determining the nearest address based on the location data; and providing the determined address. 